Database Design for Smarties: Using UML for Data Modeling

and Concrete Classes and Inheritance Another recap: remember that an abstract class is one that has no instances, while a concrete class is one that can have instances. An interface is an abstract class that has no attributes and that contains only abstract operations. The more general case of the abstract class may have both. Abstract classes are meaningless without generalization relationships. What good, for example, would the Identification class be as an abstract class without its subclasses? Since you can't instantiate an object of the class, the only reason for its existence is to set up the common properties of its concrete subclasses for inheritance when you instantiate their objects.classes are meaningless without generalization relationships. What good, for example, would the Identification class be as an abstract class without its subclasses? Since you can't instantiate an object of the class, the only reason for its existence is to set up the common properties of its concrete subclasses for inheritance when you instantiate their objects. Abstract classes represent the opportunity to express intermediate concepts in your semantic hierarchy, such as ExpiringID. You create abstract classes when you see common properties that make sense as a cohesive cluster of behavior. Sometimes this corresponds to an easily understood object, and sometimes it doesn't. If it doesn't, check and double-check your design to make sure you're not introducing too much abstraction. Simpler is better, and the shallower you keep your inheritance hierarchy the better. Note An interface is an abstract class, but not all abstract classes are interfaces. While you can't have methods implementing operations in an interface, you can in an abstract class that is not an interface. This lets you share common behavior in concrete subclasses.classes represent the opportunity to express intermediate concepts in your semantic hierarchy, such as ExpiringID. You create abstract classes when you see common properties that make sense as a cohesive cluster of behavior. Sometimes this corresponds to an easily understood object, and sometimes it doesn't. If it doesn't, check and double-check your design to make sure you're not introducing too much abstraction. Simpler is better, and the shallower you keep your inheritance hierarchy the better. Note An interface is an abstract class, but not all abstract classes are interfaces. While you can't have methods implementing operations in an interface, you can in an abstract class that is not an interface. This lets you share common behavior in concrete subclasses. What is the place of abstract classes in a data model? The abstract class gives you a place to put attributes and operations that you would otherwise spread around many classes. You are reducing redundancy by centralizing the implementation of these objects. When the design translates into the database schema, the lower redundancy will usually result in a more flexible schema. You may see more complexity in relational schemas because of the extra tables, but you will see fewer normalization problems and easier table management and maintenance. Multiple Inheritance Classes can have more than one more general parent superclass. If this is part of your design, you are using multiple inheritance. The world is full of such things, in reality, because the human mind imposes classification on the world, not vice versa. Humans are, if nothing else, inconsistent and complex, and we can find endless ways to classify things. Our thinking tends to overlap—good for thought, lousy for software system design.